Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

On average, my PHP page generation time is 10ms. So i should be able to execute 100 requests one after the other one (using a single core on the server, since that php is not multithreaded).

However, i'm having problems reaching 50 pages per seconds. As of now i do 25 on avg., with a medium load.

The application is really light, it consist in a read (<5KB) from a pool of SSDs, some read queries solved by indexes.

Where should i look to solve this bottleneck?

share|improve this question

closed as not a real question by symcbean, John Gardeniers, rnxrx, Ward, Michael Hampton Sep 30 '12 at 22:54

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers 2

On average, my PHP page generation time is 10ms. So i should be able to execute 100 requests one after the other one

No, this is very wrong. depending on what the code is doing it should be a lot more, if it's badly written then potentially a lot less.

How did you measure the 10ms?

some read queries solved by indexes.

Which rather implies a database - but you didn't even mention one, let alone what it's actually doing.

i'm having problems reaching 50 pages per seconds

So what's constraining the performance? Disk I/O, memory I/O? CPU?

No stats. No code. No config info. Sorry but we're even more in the dark than you are.

since that php is not multithreaded

No - it's multi-processing - or at least it should be (unless it happens to be handling a message queue rather than webserver requests). If you've only allowed one PHP instance in the fastcgi config (again you don't say which fastcgi manager you are using) then that's probably the biggest bottleneck.

share|improve this answer
    
16ms is the misured with microtime() at the begin and the end of the php script. It misses some overhaed. The DB is not the bottleneck, i know that for sure. I don't know what the bottleneck is. I find it hard to think it's the SSD (it's an array of 40 SSD in raid10), also i don't think it's the CPU (2*AMD 6272); it could be the ram I/O, i don't know how to measure it. About php and multithreaded i meaned that a single execution is executed by one CPU. –  cedivad Sep 27 '12 at 14:16
    
There is a huge amount of stuff going on before your PHP code starts executing - not least URL parsing, parameter parsing, PHP loading, parsing and compilation....i meaned that a single execution is executed by one CPU - so is a a single light weight process in a multi-threaded environment. –  symcbean Sep 27 '12 at 22:34
    
...and even on a very simple application the max req/s will not be 1/(time for a single request*number of CPUs) –  symcbean Sep 27 '12 at 22:51
    
Thank you. So do you think that I simply reached the limits for this server? –  cedivad Sep 28 '12 at 4:56
    
Or did I misunderstood your answer? –  cedivad Sep 28 '12 at 5:18

I don't know if this is going to help your issue, but I was also seeing request per second figures similar to those on one of our projects (We used Apache Benchmark to ascertain our rps).

We realised that it was PHP itself that was the bottleneck. In its normal form PHP parses the requested PHP files each time they are called, and this can be a lengthy and expensive operation computationally speaking. I would think that there's the start up and parsing of each PHP file to include on top of the actual execution time of the script.

PHP-APC is a cacheing mod for PHP that stores an op-code copy of the original PHP script in memory. Since it is compiled and stored in RAM it is many many times faster than uncached PHP.

After I installed PHP-APC and restarted the server, immediately we were able to pump out over 200 requests per second.

As I say, it might not help your issue, but it's worth a try.

More on PHP APC: http://php.net/manual/en/intro.apc.php

share|improve this answer
    
Using a PHP opcode cache will nearly always improve performance - but it would have been helpful if you'd mentioned the symptoms which went along with the slow performance - which would have been high CPU usage and high memory usage. –  symcbean Sep 26 '12 at 21:24
    
We had no 'symptoms' per se. Using ab would produce a higher CPU reading anyway so might not have been all that helpful. We were experiencing a low amount of requests per second, and investigated it further. It seemed logical for a scripting language to have this issue potentially so we investigated the options for compiling or cacheing, and we got what I have mentioned. As I say, it solved our problem immediately. –  TenaciousC Sep 26 '12 at 21:26
    
If you a 20-fold increase just from using an opcode cache then something else, other than php processing has speeded up massively. An opcode cache will, at best give a 3-4 fold increase in PHP performance (although doubling the performance is more realistic). OTOH it will also massively reduce memory consumption if set up correctly - which can have this kind of impact on VFS I/O –  symcbean Sep 26 '12 at 21:38
    
No we genuinely made no other changes other than installing PHP APC. I thin k we actually got to about 600 not 800, IIRC, but its a while ago and I may be right off with the figures, but it was significant. This site from Zend shows 185% increase, somewhere near the bottom: devzone.zend.com/1812/using-apc-with-php Either way, it's worth a shot. –  TenaciousC Sep 26 '12 at 21:41
    
Just be aware that PHP-APC is not a one "size fits all" solution. e.g. It can't be used on some small systems due to memory constraints. –  John Gardeniers Sep 26 '12 at 21:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.