1

Right now I have a very high volume of requests coming to my webserver which execute a PHP CGI script.

Every one of these scripts opens up a config file that I have created to load options of how the script should run.

Doing a file I/O operation everytime a request comes in seems very resource intensive to me. I'm not too familiar with the advanced features of PHP, are there any alternatives to achieve what I'm doing?

Improve this question

3 Answers 3

Reset to default
3

it seems or you have profiled your app and found that this include is the worst bottleneck?

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I have not profiled my app. But intuitively it seems this could be a problem in the future.
@teehoo your intuition has wronged you. Your server does zillion of i/o operations to serve each request. But you stuck with only one - a file that for sure already cached and served from the RAM. It is totally useless to guess. Do yourself a favor - profile your app, or every your move would be like blind man's in the dark
@teehoo Col. Shrapnel is right, this is not going to be your major bottleneck, even in the future. I have worked for web portals with millions of hits a day based on PHP, where dozens of includes are performed on every hit (even when caching is used).
1

Here are some ideas for you:

  • You could put the data in session, which can store data for each user.

  • Alternatively you could cache parameters in memory using a tool such as memcached.

  • Alternatively you could place configuration options in a PHP file instead of in a config file. This would simplify the parsing, and would also allow for caching if you are using a tool such as eAccelerator that automatically caches compiled PHP scripts.

In any case, before making optimizations you really should profile your application to identify the actual bottlenecks.

Improve this answer

2 Comments

however the default session handler is also a file on the filesystem
Thanks, I didn't profile my app yet, but I thought it is common sense to avoid doing file I/O as much as possible. But if the session handler is also based on reading files then perhaps my approach is not as bad as I thought.
0

Col.Shrapnel is right. A single file access isn't really expensive. Remember you have a file access for EVERY .php script your application is composed of.

If your configuration file is in parse_ini_file() format, worry not. Parsing it is even faster than a PHP script. However, if you are using an opcode cache, you could turn your configuration script into a PHP array / data script. This way the disk I/O gets redundant, as your opcode cache keeps Zend bytecode in memory.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.